I. Technical Field
The present invention generally relates to the field of data processing and to software-based tools for modeling and executing processes. More particularly, and without limitation, the invention relates to systems and methods for transforming modeled processes into executable processes. The modeled processes may comprise graphically modeled business processes. The executable processes may comprise processes suitable for execution by a computerized or software-based system.
II. Background Information
Business processes are the driving factors of a successful company. On the operational level, business processes are a description of consecutive functions or activities in order to create added value. Business processes may relate to various activities of a company, such as the handling of purchase orders or product returns. Business processes can also be used to describe the interaction between various types of business information, such as the organization of a business, data used by a business, functions that describe the operation of a business, and products or services offered by a business.
Successful companies often design their processes with the help of modeling tools. Modeling tools can depict, analyze and optimize the development of a business process, and can be used with other types of business information as well. A “modeling tool” may include software and/or other computerized components or modules that can be used to plan a business process or other business information, and can be used to model all or part of a business process or other aspects of a business. By way of example, a modelling tool can be used to generate descriptions of business information in a “description notation.” A description notation can be a format for written or executable computer code, such as WSDL (Web Services Description notation) or BPEL (Business Execution Language for Web Services), or a description notation can be a formalized way of graphically illustrating concepts, such as EPC (event-driven process chain) or VAC (value-added chain diagram).
Modeling tools are commercially available from various vendors. For example, the ARIS Platform of IDS Scheer AG (Saarbruecken, Germany) has been a market leader for Business Process Modeling tools. ARIS provides several description notations proven in practice to enable businesses to optimize their strategy and processes. By providing description notations well suited for modeling different facets of a business, ARIS enables business information to be modeled at varying levels of detail, and from different perspectives or “views.”
The description notations used by ARIS are structured into five (5) views to present an organized description of business information. These views include: (i) Organization: description of the organizational structure; (ii) Data: description of the business data structure; (iii) Functions: description of the business tasks regarding the hierarchical structure; number and structure of applications supporting the execution of the business tasks; (iv) Product/Services: description of products and services produced by the company; and (v) Processes (or control): description of the interaction of elements originated from the four (4) views mentioned above. In addition, each view can be partitioned into different levels, known as a view hierarchy. For example, the view hierarchy for the process/control view is known as the process hierarchy: requirements definition; design specification; and implementation description. View hierarchies can be defined for each view, and can be supplemented or modified if the user so desires.
Each of the five views ARIS defines for business information can be modeled using description notations provided by ARIS, and different description notations can be used for different levels within a view. Thus, a “business information model” can be created for the process view, and called a “business process model.” Similarly, for a data view, a “business data model” could be created, and for an organization view, a “business organization model” could be created. Each business information model can provide information relevant to one or more levels of the view hierarchy for the view with which it is relates, i.e. business data models provide information about levels of the data hierarchy. Models at different levels can be used to provide various degrees of refinement at different layers of a view hierarchy. As an example, the process view, also known as the control view, can be modeled differently at the requirements definition, design specification, and implementation description levels, with each of the levels providing different degrees of refinement about processes that occur within the business.
The requirements definition level describes the business problem in a user-friendly way, but also serves as a formal description that can be starting point for a consistent transformation into an information technology (IT) implementation. Typically, ARIS users will generate VAC diagrams for the most basic explanation at the requirements level, and use EPC diagrams to describe in more detail the requirements for steps in the VAC diagrams.
An EPC diagram is an ordered graphical representation of events and functions. Further, an EPC diagram provides connectors that allow alternative and parallel execution of processes. For example, EPC diagrams may include logical operators, such as OR, AND, and XOR, that describe relationships between elements of the process. An “element” may refer to one step or activity, for example. Additionally, in an EPC model, logical relationships between elements are termed a “control flow.” However, an EPC model, while graphical, does not actually implement a business process. It is merely a schematic representation of a business process.
Using EPCs, the procedural organization of a company can be defined. Links between concepts within the data, function and organizational view can be used to represent various business processes. The EPC can thus be used to describe the details of functions or activities within a business process. EPCs can be thought of as logical models, appropriate generally for modeling business processes or other views of a business.
The design specification level is used to transfer the terms from the requirements definition level into categories suitable for realization by information technology. If the EPC from the requirements definition level has functionality which is amenable to being implemented by web services, it can be advantageous to create a model that is tied to executable code written in, for example, Business Process Execution Language (BPEL). BPEL is an XML-based standardized language that is commonly used by companies for service orchestration. Examples of other languages include XML Process Definition Language (XPDL) and Electronic Business XML (ebXML). From a general perspective, BPEL is like a programming language containing elements for creating loops, sequences, conditions, etc. BPEL provides a standardized interface for web services and can be used across both computer platforms and organizational entities.
The BPEL standard, however, does not define a graphical means of representing BPEL code. As a result, BPEL itself is not ideal for design specification modeling by non-technical personnel. As described in U.S. Patent Publication Nos. US-2006-0293941-A1 and US-2007-0005618-A1, the disclosures of which are expressly incorporated herein by reference to their entireties, ARIS provides a graphical description notation for the representation of BPEL processes in a BPEL Process Model (BPM) and BPEL Allocation diagrams (BPADs). Using this notation, BPEL code can be represented abstractly in a BPM, and elements within the BPM can be described in more detail by using BPADs. In this way, a user can formally describe technical aspects of a business process, in a graphical description notation as BPMs and BPADs. BPEL-compliant XML code can be generated from BPMs and BPADs, so that web services can be invoked to implement various steps in the business process. ARIS users can also use UML as a description notation to model processes at the design specification level. In either case, the design specification description can remain independent of the implementation of functionality described in the model.
While business processes can be modeled directly in BPEL using the ARIS graphical notation, BPEL is generally a language used by technical specialists, and not by business process designers. Having technical specialists, rather than business process designers, do the business process modeling can have undesirable consequences. For example, the business process may be designed with an eye to the technical constraints faced by the technical specialists, rather than the more paramount considerations of the business process designers. In turn, this can result in a business process modeled in BPEL that does not optimally address the business needs of an organization. As a further example, an EPC may include additional information not relevant for execution, like costs and risks associated with business functions. In a similar manner, a BPEL model may contain technical details not relevant for the business expert, like technical exception handling
In many cases, it is more desirable that business process designers, rather than technical specialists, do the business process modeling. This goal is most readily achieved by allowing business process designers to use a language of their choice, such as EPCs. However, once the business processes have been modeled in EPCs, they must still be manually converted into BPEL code or the like before they can actually be executed. Therefore, it is further desirable to automate the conversion of EPCs created by business process designers into executable processes, such as those implemented with BPEL code.